Measuring conversion of an online advertising campaign from an offline merchant

ABSTRACT

A technique for tracking conversion of an online offer includes tracking online and/or offline transactions. A customer accepts an offer provided by a merchant and submits his or her account information so that he or she may receive a reward for satisfying criteria associated with the offer. Transactions of the merchant are then monitored at the payment processor level to determine whether the customer satisfies the purchase criteria. Therefore, online and offline conversion can both be tracked. Further, the merchant is able to determine the overall effectiveness of advertising campaigns by analyzing the number of offers that are both accepted and satisfied.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation Application of U.S. application Ser.No. 16/924,795, entitled “MEASURING CONVERSION OF AN ONLINE ADVERTISINGCAMPAIGN FROM AN OFFLINE MERCHANT,” filed Jul. 9, 2020, which is aContinuation Application of U.S. application Ser. No. 13/211,253,entitled “MONITORING FOR OFFLINE TRANSACTIONS,” filed Aug. 16, 2011,which claims priority benefit to United States provisional patentapplication titled, “SYSTEM AND METHOD IMPLEMENTING REFERRAL PROGRAMS,”filed on Feb. 15, 2011, having application Ser. No. 61/442,943 and alsoclaims priority benefit to United States provisional patent applicationtitled, “SYSTEM AND METHOD FOR IMPLEMENTING PAYMENT NETWORK COOKIES,”filed on Feb. 14, 2011, having application Ser. No. 61/442,691, all ofwhich are incorporated by reference herein.

BACKGROUND Field of the Invention

The present invention relates to the field of computer software and, inparticular, to a system and method for monitoring for transactions.

Description of the Related Art

Online advertising is a form of promotion that uses the internet todeliver marketing messages to potential customers. Examples of onlineadvertising include contextual advertisements on search engine resultspages, banner advertisements, rich media (e.g., video) advertisements,social network advertisements, interstitial advertisements, onlineclassified advertisements, e-mail marketing, and many others.

One important aspect of an online advertisement is the online“conversion” of the online advertisement, which refers generally to acustomer completing an online transaction with an online merchant inresponse to viewing the online advertisement. Typically, when a customerviews an online advertisement, the customer's activity across one ormore web pages is tracked to determine whether a particular onlinetransaction is actually completed by the customer. One example of atracking technique is referred to as pixel-based tracking, where a 1×1pixel image-often referred to as a “web beacon”—is linked to an onlineadvertisement and included in each web page of, for example, an onlineshopping cart. The 1×1 pixel image reports information back to a managerof the online advertisement such that the manager is able to determinewhether the customer has reached an order confirmation page, indicatingthat the online advertisement was successful by resulting in aconversion.

Although many merchants provide their customers the ability to shoponline, there exists a large number of merchants that have one or morebrick-and-mortar locations, referred to herein as “offline” merchants.Though offline merchants typically do not provide an online shoppingcart to their customers, the offline merchants may nonetheless beinterested in online advertising that causes customers to visit theirbrick- and-mortar locations in an attempt to increase sales.Unfortunately, as with offline advertising (e.g., advertising inmagazines, TV, radio, etc.), it is difficult for offline merchants tomeasure the performance of their online advertising campaigns.

One attempt to measure performance of an advertising campaign involvespolling customers and asking them to share the motivation for thepurchase they are making. For example, if a customer shops at a merchantlocation during a sale, then the merchant may ask the customer, “Wheredid you hear about our sale?” Unfortunately, some customers are lazy anddo not wish to share such information with the merchant or may provideinaccurate information. Determining the effectiveness of an onlineportion of ad campaign is further complicated when the sameadvertisements are presented to potential customers through otherchannels that are not online.

As the foregoing illustrates, there is a need in the art for an improvedtechnique that overcomes the deficiencies of prior approaches.

SUMMARY

One embodiment of the invention provides a method for trackingconversion of an online offer. The method includes identifying an onlineoffer accepted by a customer; receiving a set of transactions executedat a merchant; parsing the set of transactions to determine that a setof criteria associated with the online offer has been satisfied by thecustomer via one or more transactions at the merchant; and notifying themerchant that the online offer has been satisfied by the customer.

Another embodiment of the invention provides a method for identifying anidentification code corresponding to a merchant. The method includesproviding the merchant access to an account; instructing the merchant toexecute a transaction using the account; parsing one or moretransactions made using the account to identify the transaction; andextracting from the transaction the identification code of the merchant.

Further embodiments of the present invention provide a computer-readablestorage medium that includes instructions for causing a computer systemto carry out one or more of the methods set forth above.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the inventioncan be understood in detail, a more particular description of theinvention, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. itis to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1 is a block diagram illustrating components of a system in whichembodiments of the invention may be implemented.

FIG. 2 is a screenshot of an interface configured to gather customerdata from a customer that accepts an offer, according to one embodimentof the invention.

FIG. 3 is a flow diagram of method steps for generating a merchantaccount, according to one embodiment of the invention.

FIG. 4 is a flow diagram of method steps for associating a customer withan offer, according to one embodiment of the invention.

FIG. 5 is a flow diagram of method steps for determining whether a setof offers has been satisfied, according to one embodiment of theinvention.

FIG. 6 is a flow diagram of method steps for processing a group offer,according to one embodiment of the invention.

FIG. 7 is a flow diagram of method steps for processing a referraloffer, according to one embodiment of the invention.

FIG. 8 is a flow diagram of method steps for processing an offerinvolving specific criteria, according to one embodiment of theinvention.

FIG. 9 is a flow diagram of method steps for extracting anidentification (ID) of a merchant, according to one embodiment of theinvention.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding of embodiments of the invention. Oneskilled in the relevant art will recognize, however, that the conceptsand techniques disclosed herein can be practiced without one or more ofthe specific details, or in combination with other components, etc. Inother instances, well-known implementations or operations are not shownor described in detail to avoid obscuring aspects of various examplesdisclosed herein.

FIG. 1 is a block diagram illustrating components of a system 100 inwhich embodiments of the invention may be implemented. As shown, system100 includes a merchant 102, a point of sale (POS) system 104 with anassociated database 106, an offer engine (OE) 108 with an associateddatabase 109, a payment processor 110 with an associated database 112,one or more financial institutions 114, and a network 118. As shown,merchant 102, OE 108, payment processor 110 and financial institutions114 communicate with one another via network 108, such as the internet.

Though not illustrated in FIG. 1, each of OE 108, payment processor 110and POS system 104 include conventional components of a computingdevice, e.g., a processor, system memory, a hard disk drive, inputdevices such as a mouse and a keyboard, and output devices such as amonitor.

In one embodiment, DB 106, DB 109 and/or OB 112 can be any type ofstorage system, e.g., a relational database hosted on a network filesystem (NFS) device, a storage system hosted by a cloud serviceprovider, and the like. Alternatively, DB 106, DB 109 and/or DB 112 maybe integrated in POS system 104, OE 108 and payment processor 110,respectively, such as a database hosted on a local disk and managed byan operating system.

Merchant 102 may be a brick-and-mortal physical merchant, an onlinemerchant, a mail-order/telephone-order (MOTO) merchant, and the like.Merchant 102 is capable of processing accounts of customers when theypay for goods or services offered by merchant 102. Such accounts includecredit cards, debit cards, prepaid cards, and the like. In someembodiments, merchant 102 is equipped with POS system 104. As shown, POSsystem 104 is coupled to database 106, which enables POS system 104 tostore detailed information associated with transactions between merchant102 and customers of merchant 102.

A transaction may be initiated at merchant 102 according to a variety oftechniques. For example, a cashier at merchant 102 may swipe a creditcard through a card reader included in POS system 104. Alternatively, anaccount may be delivered virtually on a customer's mobile device, whichenables a customer at merchant 102 to wave his/her mobile device infront of a contactless card reader included in POS system 104. Further,the customer may show his/her mobile device to a cashier at merchant 102who manually enters an account number of the account being used by thecustomer. Alternatively, the mobile device may include a contactlesschip or tag that is wireless-readable by POS system 104 using, e.g.,near-field-communication (NFC) technology.

Payment processor 110, in conjunction with financial institutions 114,facilitates payment transactions between merchant 102 and customersthereof, and stores the transactions in DB 112. More specifically, whena customer attempts to pay for goods and/or services offered by merchant102 using his or her account, a POS terminal submits the transactionthrough a merchant account to an acquiring bank of the merchant (i.e.,one of the financial institutions 114). The acquiring bank thentransmits a request for funds through the payment processor 110. Thepayment processor 110 routes the request for funds to the card holder'sissuing bank (i.e., the appropriate financial institution 114) forauthorization based on a type of the account. The issuing bank verifiesthe card number, the transaction type, and the amount. In some examples,the issuing bank then reserves that amount of the cardholder's creditlimit for the merchant.

For example, if payment processor 110 detects that the account is adebit card associated with a checking account of the customer, thenpayment processor 110 routes the transaction request to the bank thatissued the debit card, whereupon the issuing bank indicates to paymentprocessor 110 whether the checking account possesses sufficient funds tosatisfy the transaction request. In turn, payment processor 110indicates to the merchant acquiring bank whether the request is forfunds has been approved. If the transaction is successfully processed,then funds are transferred from the card holder's account at the issuingbank to the merchant account at the inquiring bank.

An Offer Engine (POE) 108 is configured to determine the effectivenessof advertising campaigns requested and managed by merchant 102. As shownin FIG. 1, OE 108 is in communication with both merchant 102 and paymentprocessor 110. OE 108 manages “offers” that are advertised to, possiblyaccepted by, and possibly satisfied by customers of merchant 102. Theoffer can be coupled to a reward that is given to the customer when heor she has satisfied the offer, e.g. cash-back rewards, credit cardrewards, store credit, virtual currency, and the like.

An offer may be any offer that involves a customer completing atransaction according to specific criteria, such as buying a certainamount of a product, spending a certain amount in one purchase, making apurchase at a particular time, making a number of purchases within aparticular amount of time, and the like. Offers may also involve a groupof customers completing a transaction according to specific criteria. Asis described in greater detail herein, OE 108 is configured to monitorfor transactions to determine whether the criteria for a particularoffer have been satisfied. As is also described herein, OE 108 canmonitor both online and offline transactions to determine whether thecriteria for a particular offer have been satisfied.

Offer data is stored in database 109 accessed by OE 108. The offer datais advertised to customers via webpage advertisements, email marketingcampaigns, short-message-service (SMS) messages, telemarketingcampaigns, and the like, as described herein. As described below inconjunction with FIG. 2, OE 108 provides an interface that enablescustomers (e.g., individuals) to register an account with OE 108,including their account information, and subsequently accept andcomplete offers. OE 108 subsequently monitors transactions initiated atmerchant 102 (i.e., online and/or offline) to determine whether offersare satisfied by the customers whom accepted them.

FIG. 2 is a screenshot of an interface 200 configured to gather customerdata from a customer that accepts an offer, according to one embodimentof the invention. As shown, interface 200 is accessible via a webbrowser application and includes offer advertisement widget 202, offeradvertisement widget 204, and offer acceptance form 206. Offeradvertisement widgets 202, 204, when selected by a customer (e.g., byclicking on them) enable a customer to accept offers provided bymerchant 102 (e.g., “Merchant A”). For example, the customer may acceptthe offer advertised in offer advertisement widget 202 to receive a$20.00 cash back reward for any in-store purchase over $100.00 atMerchant A. Similarly, the customer may also accept the offer advertisedin offer advertisement widget 204 to receive a $50.00 cash back rewardafter performing five in-store purchases, each being $75.00 or more, ata physical location of merchant A.

When an offer advertisement widget, such as offer advertisement widget202 or 204, is selected by a customer, an offer acceptance form 206 iscaused to be displayed within interface 200. The customer then enters avariety of information that is subsequently used by OE 108 to determinewhether the customer eventually satisfies the offer, as described infurther detail below. The customer enters the details of one or moreaccounts, including account number, expiration date, security code,billing address, etc.

In some embodiments, the customer may optionally submit his or her phonenumber and/or email address to receive additional offer notificationsfrom OE 108. When the customer provides a phone number and subsequentlysatisfies an offer, OE 108 may send an SMS message to the phone numberwith a message indicating that the offer has been satisfied. OE 108 may,in some embodiments, provide another offer to the customer foracceptance by the customer via SMS.

Additionally, the customer may submit his or her information byproviding to OE 108 credentials that link to an existing online accounthosted by an alternative online service, e.g., a Facebook account or anOauth account. In particular, OE 108 accesses the online account usingthe credentials and retrieves the required information, thereby reducingthe amount of input required by the customer.

Additionally, the customer may opt to create a customer account with OE108 when accepting, for example, an offer for the first time. In oneexample, the customer opts to create a customer account by clicking on acheckbox titled “Create Account” (not shown) and included in offeracceptance form 206, which causes a password input field to appear.Subsequently, and upon providing valid inputs to OE 108 when acceptingthe offer, OE 108 generates a customer account for the customer andstores the customer account in DB 109. In one example, the customer'semail address is assigned as a login ID and is tied to the password thatis input by the customer. In this way, when the customer acceptsadditional offers, he or she is only required to input his or her emailaddress and password by, for example, clicking the “Sign In” linkincluded in offer acceptance form 206. In this way, the customer is ableto recall his or her account information and is not required toredundantly provide his or her account information each time he or sheaccepts an offer.

Though not illustrated in FIG. 2, the customer may associate one or moreof his or her account numbers with his or her account. Thus, the OE 108can track transactions made using any one of the one or more accounts.

FIG. 3 is a flow diagram of method steps 300 for generating a merchantaccount, according to one embodiment of the invention. Persons skilledin the art will understand that, even though method 300 is described inconjunction with FIG. 1, any system configured to perform the methodsteps, in any order, is within the scope of embodiments of theinvention. A merchant account enables merchants to manage offers throughinterfaces provided by OE 108. As shown, method 300 begins at step 302,where OE 108 receives, e.g., from an administrator of merchant 102, arequest to generate a merchant account. For example, the administratormay click a “Sign Up” link found on an interface provided by OE 108 thatcauses a registration interface to be displayed.

At step 304, OE 108 receives merchant account registration information.Merchant account registration includes, for example, a merchantidentification (ID) issued to merchant 102 by the merchants acquiringbank and/or payment processor 110, where the merchant ID may be used touniquely identify transactions initiated at merchant 102. POE 110 canfilter transaction data processed by payment processor 110 such that POE110 is able to determine whether accepted offers have been satisfied. Asdescribed in further detail below, embodiments of the invention providea technique for determining a merchant ID of a merchant, since themerchant is sometimes not aware of their own merchant ID, and thuscannot provide this information to the OE 108 at step 304.

At step 306, and in response to receiving the merchant accountregistration information at step 304, OE 108 generates a merchantaccount based on the registration information. The merchant account andassociated information is stored in database 109.

At step 308, OE 108 receives one or more requests to create offers. Suchrequests may be generated by merchant 102 via interfaces provided by OE108 that enable merchant 102 to submit information associated with theoffers. For example, the merchant 102 may request an offer that providesa reward of $30.00 cash-back to customers who accept the offer andperform a purchase of $150 00 or more with the merchant in a singletransaction any time during the month of July in a given year.

At step 310, OE 108 causes the offers to be published so that they canbe accepted by and/or satisfied by one or more customers. In someembodiments, a third-party, other than the OE 108 may publish the offersaccording to the techniques described above, e.g., web marketingcampaigns, email marketing campaigns, etc. For example, merchant 102 maysubmit, for a particular offer, a list of customer email addresses towhich an email that describes the offer should be sent. The offer emailreceived by the customers may include a hyperlink that, when opened by acustomer, displays to the customer an offer acceptance form associatedwith the offer, e.g., offer acceptance form 206.

FIG. 4 is a flow diagram of method steps 400 for associating a customerwith an offer, according to one embodiment of the invention. Personsskilled in the art will understand that, even though method 400 isdescribed in conjunction with FIG. 1, any system configured to performthe method steps, in any order, is within the scope of embodiments ofthe invention. As shown, method 400 begins at step 402, where OE 108detects that a customer selects to register for an offer, e.g., viaclicking on offer advertisement widget 202.

At step 404, OE 108 determines whether a customer account exists for thecustomer. This may be determined according to a variety of techniques,including analysis of browser cookies, internet protocol (IP) addresses,login information, etc., that is accessible to OE 108 and/or provided bythe customer. For example, the customer may select a “Sign In” hyperlinkincluded in interface 200 and submit his or her login credentials,whereupon OE 108 references database 109 with the login credentials todetermine whether a customer account exists for the customer. If thecustomer holds an account with OE 108, then OE 108 may display to thecustomer a list of one or more account numbers registered with thecustomer's account and previously provided by the customer, and method400 proceeds to step 414, described below. If the customer does not holdan account with OE 108, then OE 108 displays to the customer inputfields that enable him or her to input customer account registrationinformation and accept the offer, and method 400 proceeds to step 406.At step 406, OE 108 receives customer account registration informationfrom the customer, e.g., the customer account registration informationdescribed above in conjunction with FIG. 2.

At step 408, OE 108 generates a customer account based on theregistration information. The customer account is then stored by OE 108in database 109. At step 410, OE 108 generates a data object based onone or more properties of billing information included in theregistration information. For example, OE 108 may apply a hash functionto each account number to generate a corresponding hash value for eachaccount. The hash function is configured to match a hash functionexecuted by payment processor 110 that receives and hashes the accountnumber of the customer when merchant 102 attempts to charge the customerfor goods or services. In this way, OE 108 is capable of identifyingtransactions when reviewing transaction data provided by paymentprocessor 110 and associated with merchant 102 without storing theactual account number, which advantageously decreases overall liabilityof OE 108 and increases security to the customer. At step 412, OE 108associates the data object with the customer account.

At step 414, OE 108 associates the offer with the customer account.Thus, OE 108 may subsequently compare offers accepted by the customerwith transaction data of merchants associated with the offers todetermine whether the offers are satisfied, as described in furtherdetail below in conjunction with FIG. 5.

FIG. 5 is a flow diagram of method steps 500 for determining whether aset of offers has been satisfied, according to one embodiment of theinvention. Persons skilled in the art will understand that, even thoughmethod 500 is described in conjunction with FIG. 1, any systemconfigured to perform the method steps, in any order, is within thescope of embodiments of the invention. As shown, method 500 begins atstep 502, where OE 108 receives a set of offers that have been acceptedby one or more customers. For example, OE 108 may query database 109 toreturn a set of offers that have not been marked as expired or satisfiedsuch that only outstanding and/or valid offers are processed.

At step 504, OE 108 receives a set of transactions associated withpurchases made at one or more merchants. In one embodiment, OE 108receives the set of transactions by querying payment processor 110 forparticular transactions from one or more merchants. In one example, OE108 may transmit to payment processor 110 both an ID of a merchant and aset of hashed account numbers associated with customers who haveaccepted at least one offer with the merchant. In response, paymentprocessor 110 returns transactions that match the hashed accountnumbers. In another embodiment, a merchant can give the paymentprocessor 110 permission to deliver all transactions from the merchantto a third party, such as OE 108. For example, the transactions can bedelivered to the OE 108 periodically (e g., daily) or in real-time.

At step 506, OE 108 sets a first offer in the set of offers as a currentoffer. At step 508, OE 108 determines whether criteria of the currentoffer are satisfied by one or more transactions in the set oftransactions. In one embodiment, each offer is associated withexecutable code that, when executed by OE 108, enables OE 108 todetermine whether the current offer has been satisfied by one or moretransactions in the set of transactions. For example, if a customeraccepts an offer that requires him or her to make an in-store purchaseat merchant 102 between the hours of 5:00 PM-6:00 PM, and OE 108determines from a transaction in the set of transactions that a customerperforms a purchase at merchant 102, then OE 108 analyzes timestamp dataincluded the transaction to determine whether the transaction wasperformed between the required hours.

If, at step 508, OE 108 determines that criteria of the current offerare not satisfied by one or more transactions in the set oftransactions, then method 500 proceeds to step 512. Otherwise, at step509, OE 108 determines whether the one or more transactions identifiedat step 508 are associated with an account number that matches anaccount number associated with the current offer. In one embodiment, OE108 extracts a hashed account number from each transaction and comparesthe hashed account number against the hashed account number associatedwith the current offer. If, at step 509, OE 108 determines that the oneor more transactions identified at step 508 are not associated with anaccount number that matches an account number associated with thecurrent offer, then method 500 proceeds to step 512. Otherwise, method500 proceeds to step 510.

At step 510, OE 108 notifies a merchant associated with the currentoffer that the current offer has been satisfied. In one embodiment, OE108 is configured to lookup via database 109 notification preferences ofthe merchant that is associated with the current offer. For example, OE108 may determine that the merchant associated with the current offerprefers to receive a daily batch file emailed at the end of each day,where the batch file includes line-by-line detail of each customer whosatisfied an offer and the reward that is to be given to them. Inaddition to notifying the merchant, OE 108 may also be configured tonotify the customer associated with the current offer that he or she hassatisfied the current offer, as described above in conjunction with FIG.2.

At step 512, OE 108 determines whether additional offers are in the setof offers. If, at step 512, OE 108 determines that additional offers arein the set of offers, then at step 514, OE 108 sets a next offer in theset of offers as the current offer. In this way, each of the offers inthe set of offers are compared against the set of transaction data.

FIG. 6 is a flow diagram of method steps 600 for processing a groupoffer, according to one embodiment of the invention. Persons skilled inthe art will understand that, even though method 600 is described inconjunction with FIG. 1, any system configured to perform the methodsteps, in any order, is within the scope of embodiments of theinvention. As shown, method 600 begins at step 602, where OE 108determines that a group offer accepted by a first customer requires thatone or more additional customers both accept and satisfy the groupoffer.

At step 604, OE 108 determines whether the one or more additionalcustomers have accepted the group offer. In one example, the firstcustomer accepts a group offer that requires a total of ten or morecustomers to spend $25.00 or more with merchant 102. In this case, OE108 parses accepted group offers included in database 109 to determinewhether nine or more different customers, in addition to the firstcustomer, have also accepted the group offer.

If, at step 604, OE 108 determines that the one or more additionalcustomers have not accepted the group offer, then the group offer hasnot been satisfied, and method 600 ends. Otherwise, method 600 proceedsto step 606, where OE 108 receives a set of transactions associated withpurchases made by the first customer and the one or more additionalcustomers according to the techniques described above in conjunctionwith FIG. 2. Alternatively, OE 108 may receive from payment processor110 a set of all transactions associated with merchant 102 and filterout transactions that are not relevant to the group offer.

At step 608, OE 108 determines whether the first customer and the one ormore additional customers have all satisfied the group offer. If, atstep 608, OE 108 determines that the first customer and the one or moreadditional customers have all satisfied the group offer, then method 600proceeds to step 610, where OE 108 notifies a merchant associated withthe group offer that the group offer has been satisfied.

FIG. 7 is a flow diagram of method steps 700 for processing a referraloffer, according to one embodiment of the invention. Persons skilled inthe art will understand that, even though method 700 is described inconjunction with FIG. 1, any system configured to perform the methodsteps, in any order, is within the scope of embodiments of theinvention. As shown, method 700 begins at step 702, where OE 108determines that a referral offer accepted by a first customer requiresthat one or more additional customers recommended by the first customerboth accept and satisfy an offer associated with the referral offer.

In one example, the first customer is exposed to an offer advertisementwidget for a referral offer that requires him or her to get additionalcustomers to both accept and satisfy an offer, where the offer requiresthem to make a purchase of $25.00 or more at merchant 102. Typically,the offer provides incentive to the five or more friends to both acceptand satisfy the referral offer, such as $5.00 cash back for making the$25.00 purchase. In turn, the first customer is rewarded $50.00 bymerchant 102 when each of the five or more friends both accept andsatisfy the offer. The first customer may notify the five friendsaccording to a variety of techniques, such as submitting their emailaddresses into an interface provided by OE 108, which then delivers anotification of the offer to each email address.

At step 704, OE 108 determines whether the one or more additionalcustomers have accepted the offer. If, at step 704, OE 108 determinesthat the one or more additional, customers have accepted the offer, thenmethod 700 proceeds to step 706, where OE 108 receives a set oftransactions associated with purchases made by the additional customers.Otherwise, the referral offer remains outstanding, and method 700 ends.

At step 708, OE 108 determines whether the one or more additionalcustomers have all satisfied the offer. Continuing with the exampledescribed above at step 702, OE 108 determines whether each of the fivecustomers have made a purchase of $25.00 or more with merchant 102. If,at step 708, OE 108 determines that the one or more additional customershave all satisfied the offer, then method 700 proceeds to step 710,where notifies a merchant associated with the referral offer that thereferral offer has been satisfied.

As described above, OE 108 is configured to manage various types ofoffers using typical transaction data provided by payment processor 110.Typical transaction data includes properties such as a uniquetransaction ID, a merchant ID, the customer's card information, a totalamount charged, and a timestamp. Though the total amount charged to thecustomer is included in the transaction data, important data pertainingto the breakdown of the total amount charged—among other more detailedinformation—is absent from the transaction data, which may beadvantageously used by OE 108 to provide offers that are targetedtoward, e.g., purchasing specific items from merchant 102.

Such detailed information is often stored in POS system 104 used bymerchant 102 to process transactions. In one example, merchant 102charges a customer $108.00 in total for five $20.00 items purchased, andan 8% sales tax on the total price. As described above in conjunctionwith FIG. 1, POS system 104 requests payment processor 110 to processthe transaction, and payment processor 110 returns to POS system 104 thetransaction ID of the transaction if the transaction is successfullyprocessed. In turn, POS system 104 creates in database 109 a new POStransaction object that includes, e.g., a unique POS transaction ID,universal product codes (UPC) codes of each of the five items, productdetails of each of the five items, a subtotal amount, a tax amount, atotal amount, and the transaction ID returned by payment processor 110.Moreover, many POS systems provide application programming interfaces(APIs) that enable administrators to extract transaction data to, e.g.,process returns, calculate performance, and the like.

FIG. 8 is a flow diagram of method steps 800 for processing an offerinvolving specific criteria, according to one embodiment of theinvention. Persons skilled in the art will understand that, even thoughmethod 800 is described in conjunction with FIG. 1, any systemconfigured to perform the method steps, in any order, is within thescope of embodiments of the invention. As shown, method 800 begins atstep 802, where OE 108 determines that an offer accepted by a customerrequires processing transactional data collected by a point-of-sale(POS) system, e.g., POS system 104.

At step 804, OE 108 obtains the POS transaction data from POS system104. In one embodiment, POS system 104 is configured to upload POStransaction data to OE 108 at regular intervals. In another embodiment,POS system 104 is configured to query POS system 104 via an API thatprovides access to POS system 104 to retrieve the POS transaction data.

Next, the optional step 806 enables OE 108 to verify that the purchasedid in fact take place and that no corruption of POS system 104 hasoccurred. More specifically, at step 806, OE 108 optionally obtains froma payment processor, e.g., payment processor 110, transaction data thatis related to the POS transaction data. In one example, OE 108 extractsthe transaction ID from the POS transaction data which, as describedabove, is returned by payment processor 110 for each transaction that issuccessfully processed. OE 108 then queries payment processor 110 for atransaction that matches the transaction ID. If payment processor 110returns a transaction based on the transaction ID, then OE 108 verifiesthat the POS transaction data obtained from POS system 104 is notcorrupt. Otherwise, OE 108 may notify merchant 102 of the discrepancy.

At step 808, OE 108 determines whether the offer is satisfied based onthe transactional data. In one example, the offer requires that thecustomer purchases a medium-sized black T-Shirt to receive a $2.00reward. OE 108 then, according to the techniques described above inconjunction with FIG. 5, processes the POS transaction data to determinewhether the offer has in fact been satisfied. For example, the POStransaction data may include a “Description” field with a value“Size:M;Color:Blk” that OE 108 is able to parse and identify as apurchase that satisfies the offer. In another example, merchant 102 mayprovide a UPC code associated with medium-sized black T-Shirts to OE 108when creating the offer such that OE 108 need only verify that UPC codeincluded in the POS transaction data is valid.

If, at step 808, OE 108 determines that the offer is not satisfied basedon the transactional data. then the method 800 ends. Otherwise. themethod 800 proceeds to step 810, where the, OE 108 notifies merchant 102associated with the offer that the customer has satisfied the offer.

FIG. 9 is a flow diagram of method steps 900 for extracting anidentification (ID) of a merchant, according to one embodiment of theinvention. Persons skilled in the art will understand that, even thoughmethod 900 is described in conjunction with FIG. 1, any systemconfigured to perform the method steps, in any order, is within thescope of embodiments of the invention. In the method 900, OE 108 isconfigured to act as an issuing bank. More specifically, OE 108 isconfigured to issue one or more pre-paid credit cards that aredistributed to merchants who are unaware of their merchant ID, which isa typical problem. When charges are attempted on such cards, OE 108receives a transaction request because the OE 108 is the issuer of thecard. The transaction received by the OE 108 includes at least amerchant ID of the merchant that is attempting to charge the card. Thetransaction may also include a date/time that the transaction wasgenerated and amount associated therewith.

As shown, method 900 begins at step 902, where OE 108 issues a creditcard to a merchant. OE 108 also maintains a hash of the numbers includedon the credit card according to the hashing techniques described abovein conjunction with FIG. 4 such that comparisons can be made in a securemanner.

At step 904, OE 108 instructs merchant 102 to execute a transaction at aspecified time and/or for a specified amount of money. In one example,merchant 102 is instructed by OE 108 to attempt a charge for $11,302.34on Jan. 23, 2011 between the hours of 3:00 PM and 4:00 PM.

At step 906, OE 108 identifies the transaction. In one embodiment, OE108 is configured to automatically identify the transaction when arequest for the transaction is received. In another embodiment, OE 108is configured to parse a set of transactions, e.g., at the end of eachday, to identify the transaction. At step 908, OE 108 extracts amerchant ID associated with the identified transaction. In turn, themerchant ID may be used to register a merchant account, as describedabove in conjunction with FIG. 3. In some embodiments, the OE 108 maythen decline the transaction so that no funds are actually transferredbetween financial institutions.

Advantageously, embodiments of the invention provide an improvedtechnique for monitoring for offline transactions. A customer accepts anoffer provided by a merchant and submits his or her account informationso that he or she may receive a reward for satisfying criteriaassociated with the offer. Transactions of the merchant are thenmonitored to determine whether the customer satisfies the purchasecriteria. As a result, the merchant is able to determine the overalleffectiveness of advertising campaigns by analyzing the number of offersthat are both accepted and satisfied.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof. For example, aspects of thepresent invention may be implemented in hardware or software or in acombination of hardware and software. One embodiment of the inventionmay be implemented as a program product for use with a computer system.The program(s) of the program product define functions of theembodiments (including the methods described herein) and can becontained on a variety of computer-readable storage media. Illustrativecomputer-readable storage media include, but are not limited to: (i)non-writable storage media (e.g., read-only memory devices within acomputer such as CD-ROM disks readable by a CD-ROM drive, flash memory,ROM chips or any type of solid-state non-volatile semiconductor memory)on which information is permanently stored; and (ii) writable storagemedia (e.g., floppy disks within a diskette drive or hard-disk drive orany type of solid-state random-access semiconductor memory) on whichalterable information is stored. Such computer-readable storage media,when carrying computer-readable instructions that direct the functionsof the present invention, are embodiments of the present invention.

In view of the foregoing, the scope of the present invention isdetermined by the claims that follow.

1. (canceled)
 2. In a system comprising a set of point of sale (POS)systems associated with a set of merchants, and a payment processorcommunicatively coupled to the set of POS systems via a network, anoffer engine to determine satisfaction of a set of offers associatedwith the set of merchants based on a set of transactions completed,using the set of POS systems, between a set of customers and the set ofmerchants in response to each customer of the set of customers receivingand accepting one or more offers of the set of offers from one or moremerchants of the set of merchants, wherein each offer of the set ofoffers specifies at least one criterion for the set of customers tosatisfy that online offer and complete the transactions with one or moremerchants of the set of merchants that provide that online offer, theoffer engine comprising: a processor; and a memory storingcomputer-readable instructions that when executed by the processor causethe offer engine to: receive the set of offers that have been acceptedby the set of customers, each offer of the set of offers including firstpayment account information; receive, from the payment processor, theset of transactions associated with purchases made by the set ofcustomers at the set of POS systems of the set of merchants, eachtransaction of the set of transactions including second payment accountinformation; for each offer of the set of offers: determine that one ormore criterion for that offer is satisfied by one or more transactionsof the set of transactions to identify one or more satisfyingtransactions; determine that that offer is satisfied for at least onesatisfying transaction of the one or more satisfying transactions whenthe second payment account information of at least one satisfyingtransaction matches first payment account information for that offer;transmit, via the network, to a merchant device of a merchant associatedwith that offer, an indication that that offer has been satisfied by acustomer of the set of customers associated with the at least onesatisfying transaction.
 3. The offer engine of claim 2, wherein thecomputer-readable instructions further include instructions that causethe offer engine to query a database for any outstanding offers, thedatabase storing the set of offers as an outstanding set of offers, andwherein the offer engine receives the set of offers in response to thequerying.
 4. The offer engine of claim 2, wherein the computer-readableinstructions further include instructions to: transmit, to the paymentprocessor, a request for transactions at the set of merchants, therequest including: a merchant identifier for each merchant of the set ofmerchants, wherein the merchant identifier was previously issued to themerchant by the payment processor and communicated to the offer engineby the merchant; and hashed first payment account information based onthe first payment account information from the set of offers that havebeen accepted by the set of customers, wherein the offer engine receivesthe set of transactions in response to the transmitting the request fortransactions, and wherein the set of transactions include transactionswhere the second payment account information matches the hashed firstpayment account information.
 5. The offer engine of claim 4, wherein thecomputer-readable instructions that cause the offer engine to determinethat that offer is satisfied further for the at least one satisfyingtransaction includes instructions to determine that the offer issatisficed when the hashed second payment account information of thelast least one satisfying transaction matches the hashed first paymentaccount information for that offer.
 6. The offer engine of claim 2,wherein the one or more criterion include a specification of a timeperiod, and wherein the computer-readable instructions that cause theoffer engine to determine that that offer is satisfied further includeinstructions to determine that timestamp information associated with oneor more satisfying transactions satisfies the specification of the timeperiod.
 7. The offer engine of claim 2, wherein the one or morecriterion include a specification of a minimum amount of a product. 8.The system of claim 2, wherein the one or more criterion include aspecification of a minimum spend for that transaction of the set oftransactions.
 9. The system of claim 2, wherein the one-or morecriterion include a specification of a minimum number of transactionswithin a time period.
 10. The system of claim 2, wherein thecomputer-readable instructions further include instructions to:transmit, via the network, to a customer device of the customer of theset of customers that was determined to satisfy that offer, anindication that that offer has been satisfied by that customer.
 11. Amethod to determine satisfaction of a set of offers associated with aset of merchants based on a set of transactions completed, using a setof point of sale (POS) systems associated with the set of merchants anda payment processor communicatively coupled to the set of POS systemsvia a network, between a set of customers and the set of merchants inresponse to the each customer of the set of customers receiving andaccepting one or more offers of the set of offers from one or moremerchants of the set of merchants, wherein each offer of the set ofoffers specifies at least one criterion for the set of customers tosatisfy that online offer and complete the transactions with one or moremerchants of the set of merchants that provide that online offer, themethod comprising: receiving the set of offers that have been acceptedby the set of customers, each offer of the set of offers including firstpayment account information; receiving, from the payment processor, theset of transactions associated with purchases made by the set ofcustomers at the set of POS systems of the set of merchants, eachtransaction of the set of transactions including second payment accountinformation; for each offer of the set of offers: determining whetherone or more criterion for that offer is satisfied by one or moretransactions of the set of transactions to identify one or moresatisfying transactions; determining that that offer is satisfied for atleast one satisfying transaction of the one or more satisfyingtransactions when the second payment account information of at least onesatisfying transaction matches first payment account information forthat offer; transmitting, via the network, to a merchant device of amerchant associated with that offer, an indication that that offer hasbeen satisfied by a customer of the set of customers associated with theat least one satisfying transaction.
 12. The method of claim 11, furthercomprising: transmitting, to the payment processor, a request fortransactions at the set of merchants, the request including: a merchantidentifier for each merchant of the set of merchants, wherein themerchant identifier was previously issued to the merchant by the paymentprocessor; and hashed first payment account information based on thefirst payment account information from the set of offers that have beenaccepted by the set of customers, wherein the receiving the set oftransactions is in response to the transmitting the request fortransactions, and wherein the set of transactions include transactionswhere the second payment account information matches the hashed firstpayment account information.
 13. The method of claim 12, the determiningthat that offer is satisfied further including determining that theoffer is satisfied when the hashed second payment account information ofthe last least one satisfying transaction matches the hashed firstpayment account information for that offer.
 14. The method of claim 11,further comprising querying a database for any outstanding offers, thedatabase storing the set of offers as an outstanding set of offers, andwherein the receiving the set of offers is in response to the querying.15. The method of claim 11, wherein the one or more criterion includeone or more of: a specification of a time period within which thattransaction of the set of transactions must be executed; a specificationof a minimum amount of a product; a specification of a minimum spend forthat transaction of the set of transactions; or a specification of aminimum number of transactions within a time period.
 16. The method ofclaim 11, wherein the computer-readable instructions further includeinstructions to: transmit, via the network, to a customer device of thecustomer of the set of customers that was determined to satisfy thatoffer, an indication that that offer has been satisfied by thatcustomer.
 17. A non-transitory computer-readable storage medium encodedwith instructions to determine satisfaction of a set of offersassociated with a set of merchants based on a set of transactionscompleted, using a set of point of sale (POS) systems associated withthe set of merchants and a payment processor communicatively coupled tothe set of POS systems via a network, between a set of customers and theset of merchants in response to the each customer of the set ofcustomers receiving and accepting one or more offers of the set ofoffers from one or more merchants of the set of merchants, wherein eachoffer of the set of offers specifies at least one criterion for the setof customers to satisfy that online offer and complete the transactionswith one or more merchants of the set of merchants that provide thatonline offer, wherein the instructions, when executed, cause one or moreprocessors to: receiving the set of offers that have been accepted bythe set of customers, each offer of the set of offers including firstpayment account information; receiving, from the payment processor, theset of transactions associated with purchases made by the set ofcustomers at the set of POS systems of the set of merchants, eachtransaction of the set of transactions including second payment accountinformation; for each offer of the set of offers: determining whetherone or more criterion for that offer is satisfied by one or moretransactions of the set of transactions to identify one or moresatisfying transactions; determining that that offer is satisfied for atleast one satisfying transaction of the one or more satisfyingtransactions when the second payment account information of at least onesatisfying transaction matches first payment account information forthat offer; transmitting, via the network, to a merchant device of amerchant associated with that offer, an indication that that offer hasbeen satisfied by a customer of the set of customers associated with theat least one satisfying transaction.
 18. The non-transitorycomputer-readable storage medium of claim 17, wherein the instructions,when executed, further cause the one or more processors to:transmitting, to the payment processor, a request for transactions atthe set of merchants, the request including: a merchant identifier foreach merchant of the set of merchants, wherein the merchant identifierwas previously issued to the merchant by the payment processor; andhashed first payment account information based on the first paymentaccount information from the set of offers that have been accepted bythe set of customers, wherein the receiving the set of transactions isin response to the transmitting the request for transactions, andwherein the set of transactions include transactions where the secondpayment account information matches the hashed first payment accountinformation.
 19. The non-transitory computer-readable storage medium ofclaim 18, wherein the instructions, when executed, cause the one or moreprocessors to determine that that offer is satisfied further includeinstructions that, when executed, cause the one or more processors todetermine that the offer is satisfied when the hashed second paymentaccount information of the last least one satisfying transaction matchesthe hashed first payment account information for that offer.
 20. Thenon-transitory computer-readable storage medium of claim 17, wherein thecomputer-readable instructions further include instructions that, whenexecuted, cause the one or more processors to query a database for anyoutstanding offers, the database storing the set of offers as anoutstanding set of offers, and wherein the receiving the set of offersis in response to the querying.
 21. The non-transitory computer-readablestorage medium of claim 17, wherein the one or more criterion includeone or more of: a specification of a time period within which thattransaction of the set of transactions must be executed; a specificationof a minimum amount of a product; a specification of a minimum spend forthat transaction of the set of transactions; or a specification of aminimum number of transactions within a time period.